Skip to content
This repository was archived by the owner on May 6, 2021. It is now read-only.

Conversation

@sunfch
Copy link

@sunfch sunfch commented Dec 6, 2015

Ignore the entries of the pending state.
When put a object to radosgw, there are two bilogs to generate. One is "pending" state, the other is "complete" state.
This should be ignored when the entry is "pending" state, otherwise the same object will be copied twice.

Ignore the entries of the pending state. 
When put a object to radosgw, there are two bilogs to generate. One is "pending" state, the other is "complete" state. 
This should be ignored when the entry is "pending" state, otherwise the same object will be copied twice.
@ceph-jenkins
Copy link
Collaborator

Can one of the admins verify this patch?

@alfredodeza
Copy link
Contributor

ok to test

@yehudasa
Copy link
Member

@sunfch on the surface the suggestion is fine. Note that there might be a case where some objects will miss the commit entry, e.g., if rgw crashed between the prepare and the commit. There should be some mechanism to handle that (e.g., handle entries that were in the prepare state but without commit following).

@sunfch
Copy link
Author

sunfch commented Dec 15, 2015

@yehudasa if rgw crashed between the moment that a object is uploaded completely and the commit entry is not still written to disk, radosgw-agent that applied this pull request will miss the object. Have I understood correctly?
If the entry in prepare state and the entry in complete state for the object are all exist, the prepare entry should been ignored. If there is no entry in complete state for a object, how should the entry in prepare state for the object be processed? Have you good idea for that?
Thanks

@goukiwang
Copy link

Good job @sunfch !! I meet the same problem as you did, the usage of secondary zone is twice to the master.
I have one concern to your change, is there any necessary to add entry.op == 'write' into if statement? there are also duplicated log entries with op =='del' which will cause an object to be delete twice, and this change will not take effect to them.

@sunfch
Copy link
Author

sunfch commented Mar 29, 2016

@goukiwang
You are right!
I did not delete objects at master zone, so I did not run into that case.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants